权限设计 内容 概述 概述 通常,权限分为功能权限和内容权限。 功能权限: 菜单权限:设置菜单记录是否显示 (按角色分配菜单记录) 工具栏权限:设置工具栏图标是否显示(单独工具栏权限窗口) 界面权限:设置AD对象是否显示或者可桌面搜索(角色窗口权限设置) 流程权限:设置流程/报表是否可用(角色窗口权限设置) 工作流权限:设置工作流是否可用(单独工作流用户和权限设置窗口) 单据操作权限:与流程权限不同,每个单据表都包含”单据操作Doc_Action“字段,通过角色窗口单独设置操作权限记录。 内容权限: 组织访问权限:设置用户可以访问的组织(角色窗口权限设置) 界面内容权限:设置字段是否显示(角色层表级权限控制窗口) 字段内容权限:设置字段是否过滤,按权限匹配显示() 报表内容权限:设置报表是否可用,报表内容是否按权限匹配(与流程一致,按角色分配权限) 提示内容权限:设置状态栏提示内容是否显示,按权限匹配(【默认无解】) 桌面内容权限:设置桌面显示的(单独桌面内容窗口设置权限) 仪表盘内容权限:设置仪表盘内容是否显示(绩效指标内容按角色分配) 权限管理包括:权限设计,权限申请,权限维护三块内容。 ==权限设计== 总体要求:面向业务,安全,可管理 通常复杂组织的权限管理架构是三层:公用角色--本地角色--岗位角色。 公用角色(ID设计):没有组织访问,只设置功能访问,供本地角色继承(分配给本地角色使用)。 本地角色(实施经理设计):按需求设置组织权限,再累加所分配的公用角色权限。 岗位角色(客户关键用户设计):多个本地角色的合集。 多组织使用公用角色是必须的,可以大大减少角色的设置工作。不同组织角色只需设置本地角色继承公用角色即可。但对于小型企业或者组织,架构可以减为二层:本地角色--岗位角色。 与大型软件不同,id没有内置公用角色的权限设置,当有"主角色"这个选项概念,相当于共有角色,不能直接分配给用户但是能被其他角色所继承。公用角色具有面向业务性特征,比如采购业务:其公用角色有 采购-供应商管理,采购-申购,采购-商务,不同采购岗位灵活组合公用角色即可完成权限设定。 设计要求: 1. 保证公用角色的权限设置的正确性和完整性。 2. 岗位角色权限尽量细化,分配用户时灵活组合即可。 3. 保证只将岗位角色分配给用户,避免越层授权。 4. 保证权限继承的连续性,完善用户权限变更机制。 比如:用户权限变化,岗位角色组合是否满足,否,新建本地角色,再否,新建公用角色。 5. 角色编码,以利于统计和管理。 ==方案实例== 组织:组织架构影响用户和角色的权限设计。组织虚拟后,用户将工作于多个组织。 用户:默认属于一个行政组织,可以分配多个角色,可以分配多个组织访问。 角色:可以分组,支持下属角色,支持主角色(供其他角色继承权限,无法分配给用户)。 岗位:实际业务的权限实例,需要与角色权限一一对应。 设计粒度1:按实际岗位设计单独角色,无包含继承权限。 角色: 角色1:部门-经理(所有部门模块业务使用功能) 角色2:部门-全能(与经理相比,仅无审批权限) 角色3:岗位1 角色4:岗位2 角色5:部门-查询(必须,以分配其他部门用户使用) 用户: 部门经理=角色1 全能员工=角色2 岗位1=角色3 岗位2=角色4 优点:直观,继承关系简单,维护方便 缺点:权限设置重复,工作量大。 设计粒度2:按业务流程的具体权限动作设计,使用多个角色分配给用户得出目标权限 角色: 角色1:部门-岗位1 角色2:部门-岗位2 角色3:部门-查询 角色4:部门-审批 用户: 部门经理=角色1+2+3+4 全能员工=角色1+2+3 岗位1=角色1 岗位2=角色2 优点:权限设置量小。若岗位1的权限发生变化,只需修改二次,即可同步所有用户。方案1需要修改四次。 缺点:权限关系维护较复杂,如果细分作业权限,角色会更多。 ==权限实施== 流程:设计-测试-申请-实施-运维 步骤: 1. 确定业务模块 2. 分解业务功能,拟定公共角色,并设定为主角色 3. 根据组织架构,拟定各组织的本地角色,并包含相关公共角色 4. 拟定岗位角色,并包含相关本地角色。 ==权限申请== 三级流程:用户申请,部门审批,技术完成 五个功能:用户申请,部门审批,技术回执,权限报表,权限审计 通过ID系统内部的”工单请求Request“功能,可以简单完成前3个功能。权限报表需要自定义报表,在线审计需要自定义窗口。 ==权限审计== 审计目的:安全性,正确性 审计对象:管理员,超级用户,普通用户 审计内容:安全参数,权限范围,授权状态,时效性 ==权限规范== 1. 安全管理规范 2. 权限作业规范 3. 权限审计规范